by Bryan Morgan
Since its introduction in 1995, Java has dominated the computer industry's discussion of client-side Web programming. Because it was the first programming language and environment introduced with the World Wide Web specifically in mind, Java is a natural fit for developers wanting to add truly interactive content to Web pages. Some of Java's chief advantages are that it is object-oriented, multithreaded, secure, and platform-independent. However, this is not to say that it does not have its disadvantages. Currently, downloaded Java applets suffer from poor performance, are not persistent on the client, and are severely restricted on the client from performing system-level tasks. Also, despite the tremendous potential of the Web, the fact remains that the vast majority of code being written today is still being written for operating-specific, stand-alone applications.
Since 1990, Microsoft has been promoting an object model (COM) that specifies how binary objects can interact and build on each other. Object Linking and Embedding (OLE) was Microsoft's implementation of an object framework using COM. OLE provides several objects that enable the user to work in a document-centric way. This means that the document on which the user is working is the real focus, not the individual applications that are used to create the document. An OLE compound document could include word processing text, graphics, spreadsheets, sound, video, or any other OLE-compliant application's output. Simply clicking any of these objects within the document could activate the application that created the object. OLE became so successful on the Windows platform that Microsoft decided to make it the basis of its distributed computing framework. Microsoft also introduced another COM-based technology that used OLE and other COM-based objects to collectively create programming objects (OLE controls or OCX controls) that could be dropped into any OLE control- aware programming environment. Environments that currently support OLE controls include Visual Basic 4, Visual C++, PowerBuilder, Borland Delphi, Borland C++, and Access.
The explosion in Internet usage forced Microsoft to rethink many of its applications and technologies, and many parts of OLE were reworked to provide better performance, smaller code size, and a different security model. These technologies were introduced to the public in 1995 as ActiveX. ActiveX technologies currently available include the programming objects known as ActiveX controls, the ActiveX scripting engine in Microsoft Internet Explorer 3.0 (used to run VBScript and JavaScript), ActiveX Documents (see Figure 10.1), and the ActiveX Server Framework, which provides security, database access, and server-side tools.
Figure 10.1 : Microsoft Internet Explorer 3.0 displays an ActiveX document.
This chapter points out the strengths and weaknesses in Microsoft's ActiveX technology. A key point to remember is that with Microsoft Visual J++, the Java developer has both options to play with: pure Java and ActiveX. In other words, developers are no longer forced to choose between ActiveX and Java. Therefore, the decision is left up to the developer to pick the best tool for the job (which is the way it is supposed to be).
In any fair discussion, nearly every new technology has a set of advantages and disadvantages. ActiveX has been praised by many and criticized by just as many others. (In general, this usually indicates that you must be at least be doing something interesting to evoke such a large amount of discussion!) Nonetheless, with the advent of the Microsoft Internet Explorer 3.0 browser, the Microsoft Virtual Machine for Java, and Visual J++, ActiveX is going to be around for quite some time. This section focuses on the advantages of ActiveX and how it can benefit the Web programmer. To begin, you learn that you can do things with ActiveX that you simply cannot do using any other technology. This, by default, gives ActiveX an advantage in many areas where it faces no competition.
The ActiveX technologies are all binary technologies. This means that, unlike Java, there is no runtime interpreter that translates bytecodes into machine code. Therefore, downloaded components (ActiveX controls) are able to run at true machine speeds, which means ActiveX controls run much faster than comparable Java applets.
Although in some instances object persistence can be a disadvantage, when ActiveX controls are initially downloaded they are installed onto the local system and remain there. (Future versions of Internet Explorer will enable the user to set defaults that control how ActiveX controls are saved.) The next time the user visits a page containing this ActiveX control, no downloading needs to be done. Instead, the ActiveX control is embedded immediately within the form. Java applets, meanwhile, are cached on the local file system only during the Web browser's current session. The next time the user visits the Web site (after closing the browser), the applet most likely will have to be downloaded again. This might not seem like a big deal, but because many applets inherit and use a wide variety of other classes, many of these additional classes also have to be downloaded. It is not unusual for a single applet to download 50 separate class files before it can be used within the Web page.
Although Java is clearly an extremely exciting technology and might be the language of choice for many in the coming years, ActiveX technologies have been around since 1990. An extremely large base of code currently exists in the thousands of ActiveX controls available on the market today. Because of the COM foundation, all OLE controls available before the introduction of ActiveX can be downloaded and used within a Web browser just like ActiveX controls. The primary difference between ActiveX controls and OLE controls is that ActiveX controls are only required to implement one interface: Iunknown. This enables them to be potentially much smaller than OLE controls, although in some cases ActiveX controls are no different than their OLE counterparts.
ActiveX controls are hugely popular, and an entire industry already exists and thrives on their production and sales. Examples of ActiveX controls currently installed on my machine include
Although it is true that Java applets exist to perform some of the functionality previously mentioned, there are other operations listed here for which no Java applets exist whatsoever. In addition, many of the Java spreadsheet and chart classes available (to pick some examples) suffer from extremely poor performance and low functionality. Meanwhile, the market has pretty much sorted out the winners from the losers in the ActiveX control arena. Companies such as Sheridan, Micro-Help, and Visual Components have established excellent reputations for building high-performance, high-functionality ActiveX objects. Therefore, when components are purchased from these companies, there is some assurance that they will work as advertised.
You can build the following applications using Visual J++ and the controls listed previously:
The Windows Virtual Machine for Java makes all of the preceding functionality possible. You might be surprised to learn that even the Microsoft Virtual Machine itself was built as an ActiveX object. Thousands of developers have spent huge amounts of time and money investing in application development using ActiveX components. It is wishful to expect all of these developers to simply stop everything they have been doing for the past two years, retool, and begin developing Web-based Java applications. ActiveX acts as a bridge between the two technologies by enabling existing components to be reused while enabling new components to be added to applications. These components could be written in Java, Visual Basic, Delphi, C++, or any other language that supports the creation of ActiveX controls.
ActiveX objects also have one additional advantage: They can be
written in any language and can be called from any other language.
| NOTE |
Before discussing this further, let me take a moment to define the word "any" in the world of Microsoft. Developers cannot simply sit down with a Fortran compiler and immediately start using ActiveX controls. Instead, the compiler needs to be able to support the linkages between ActiveX and standard code. Likewise, for a language to call an ActiveX object, the compiler must be "ActiveX-aware" and support the hooks necessary to dynamically link together ActiveX objects with binary code. |
Under Windows 95/Windows NT, the development tools that control the lion's share of the PC software development market all support the usage of ActiveX controls. As mentioned earlier, this includes Visual Basic and C++, Delphi, PowerBuilder, FoxPro, Access, and many others. C++, Delphi, and VB 5.0 also support the creation of ActiveX controls. Therefore, an ActiveX object written in C++ could be dropped onto a Delphi form (or an HTML page for viewing in MS Internet Explorer). The word "object" is intentionally used here to mean a programming construct that encapsulates data and methods in an atomic object.
Programs written in Java, meanwhile, are limited in their capability to communicate with code written in other languages. "Native" language methods can be called through the use of native methods; however, once these methods are used, Java classes cannot "travel" to remote machines as they do when they are downloaded to a client browser. Native methods can also link only to static object code, so there is no way to dynamically update the linked-in code, as there is with ActiveX objects.
With the advent of Distributed COM in Windows NT 4.0, ActiveX objects also have the capability to communicate with other objects located on remote machines. These objects can be placed on other machines for a variety of reasons:
Much attention has been paid to the two-tier design of traditional client/server applications. In this development mode, all of the display and application logic resides on the client (the Web browser containing applets or controls, or a normal GUI application) and the database operations reside on the server. Several problems arise with this development paradigm. The biggest problem is that the display code and the application code often become so intertwined that code maintenance is extremely difficult. If you need to dramatically change a screen, a huge amount of reworking is involved before you can make the change. Breaking applications into logical portions and distributing these segments across multiple tiers (often called n-tiers) leads to better maintainability, performance, and scalability.
Believe it or not, despite the marketing hype surrounding ActiveX, it does have some real disadvantages to go with its advantages. These disadvantages are discussed in an unbiased manner in the following sections.
ActiveX is advertised by Microsoft as having "cross-platform support." Although behind-the- scenes versions of ActiveX are being readied for the Macintosh and UNIX operating systems, the fact remains that ActiveX today can be used only on Microsoft's own operating system (Windows). To Microsoft's credit, the Component Object Model (COM) in no way specifies any vendor- or platform-specific implementation features. However, so far no company besides Microsoft has stepped forward and built an implementation on top of COM.
A discussion seems to continually rage in the Java newsgroup (comp.lang.java) over whether the words "cross-platform" even matter. After all, Microsoft owns a nearly 90 percent share of the personal computing operating system market, so who cares about "cross-platform"? In other words, what good does being "cross-platform" do you if all of your customers' platforms are the same? This is an extremely interesting point and, as with all good questions, there is no easy answer. In an ideal world, each individual user could choose his computing environment based on his personal preferences. That is, the software would come to the user, rather than the user being forced to go where the software is.
Java is not completely free from this discussion, either. Even though Java code might be able to run unmodified on virtually any platform, it is unable to interoperate with other parts of the operating system. In a generic Web-centric environment, the Web browser itself could act as the operating system and applet execution environment. However, this excludes all of the applications that take advantage of operating-system features to provide more value to the end user (printing, file access, inter-application data sharing, and so on).
Microsoft has announced its intention to develop ActiveX-aware versions of its Internet Explorer browser for the Macintosh and UNIX operating systems. The time frame in which these browsers are introduced, combined with the success of the Mac and UNIX ports of ActiveX, plays a key role in the success of Microsoft's "cross-platform" ActiveX strategy.
Java was designed from the ground up to ensure that a person who used a client machine running Java code could be nearly certain that the code would not harm the local system. No matter who the developer of the Java applet is, a user can download an applet, run it, and never really think about the security implications of doing so. This is because Java applets have no capability to read or write to the local file system or to make any operating system calls (a security technique known as sandboxing). Although no system connected to the outside world via the Internet can ever be 100 percent secure, the Java language and runtime environment go a long way to prevent security flaws.
ActiveX controls, meanwhile, have full system privileges. After an ActiveX control is downloaded, your Windows Registry can be updated, and the component will be installed onto your local system. The ActiveX control can perform a directory search of the file system, change video resolutions, reboot your computer, or even grab files and send them over the Internet to a remote server. With these capabilities, no security model on earth will ever make users feel completely comfortable. Microsoft is trying, however, to convince the computer industry and the public in general of the virtues of its ActiveX security model. This model uses a technique known as code signing to verify the contents of ActiveX controls before they are downloaded.
Code signing is provided by an independent software testing facility
(called Certification Authorities) that tests code to verify that
it does what it says it does. When this software has been tested,
the code is signed using a digital signature. These signatures
contain information that can be examined by software that supports
the Microsoft Trust Verification service (Internet Explorer, for
example). Using this service, a Web browser can determine whether
a control has been modified since it was assigned a digital signature.
If it has been tinkered with, the Web browser can alert the user
or disenable downloading.
| CAUTION |
Keep in mind that ActiveX components, unlike Java applets, do not undergo any runtime verification. Therefore, after the control is installed on a machine it is free to do whatever it wants. |
ActiveX controls are not required to use code signing. In fact, Internet Explorer 3.0 offers users the ability to fully control the security level at which they want to operate (see Figure 10.2).
Figure 10.2 : The Internet Explorer Security Options dialog box.
Security can mean different things to different people. Java is secure in that Java code is unable to access the local operating system when it is running within a Web browser. ActiveX security, though not as foolproof, potentially still could provide the same level of security that is expected today when users purchase shrink-wrapped software. Perhaps the biggest problem with ActiveX security is the fact that it leads the public to trust only software produced by the major software manufacturers. A tiny, brand-new software company might have difficulty convincing the public to download and run its ActiveX code, especially when a comparable product is offered by a major manufacturer such as Microsoft.
One other disadvantage of ActiveX controls that is often ignored is their sheer size. Going back to the partial list of ActiveX controls installed currently on my machine, the following listing shows these controls and their size. Some of the controls are OLE controls and others are actual ActiveX controls, and therefore are noticeably smaller (the Stock Ticker and RealAudio controls, in particular).
In contrast, the 470 Java classes included in the Visual J++ classes.zip file take up a total of 804KB, or approximately 1.71KB each. Although it is true that some applets also download several additional classes in order to be interpreted and run, all of the 470 files in the Visual J++ class library will be included on the local Windows machine as part of the Microsoft Virtual Machine. (In other words, they don't need to be downloaded in that case.) Microsoft has gone a step further with the Visual J++ product and enabled developers to package all of the required class files for an applet together into a single .CAB file. This file is compressed on the server side, and then the individual class files are extracted from the CAB file as the Java Virtual Machine needs them. Compressing files in this way greatly reduces download time of Java classes.
Some ActiveX controls also require DLLs (dynamic link libraries) and other files to be installed along with the ActiveX control. When these controls are downloaded, an installation routine will often start and install the control onto the local machine. Although this process has to be completed only once, it still causes a long enough wait that many users might just cancel the operation altogether. Developers who have built OLE controls should obtain the ActiveX SDK and really look at converting these controls to true ActiveX controls in order to save download time.
As you probably are well aware by now, ActiveX is supported natively only in Microsoft's Internet Explorer 3.0 browser. A Netscape plug-in that enables Netscape Navigator to display pages containing ActiveX controls can be obtained from nCompass Labs, but this product is not supported by Netscape. Through the 4.0 release of Navigator, Netscape has no plans to add ActiveX support into its browser, either. All of this means that if you were to build Web pages containing ActiveX controls or Java applets communicating with ActiveX components (as you see later in this chapter), those pages would not display correctly within any browser but Microsoft Internet Explorer.
As new ActiveX-enabled versions of Microsoft Internet Explorer become available for the Macintosh and UNIX platforms, the debate is sure to change. At that point, an overwhelming majority of operating systems would feature support for ActiveX and Java, making it likely that both technologies will continue to coexist for some time to come. However, developers interested in ActiveX should realize that there is a growing contingent of users who are worried about ActiveX's security drawbacks, as well as its platform dependence. These concerns should be taken into consideration when making development choices.
All of this jockeying for position in the Web sweepstakes has left many developers' heads spinning. Microsoft continues to release a barrage of related ActiveX technologies, with little explanation of the benefits and drawbacks inherent in each technology's usage. What's worse, because of the real-time nature of the Web, many new features and products have been reported before these features are actually fully developed. (When good developers find it difficult to keep up with new technologies, non-developing journalists can rarely be relied upon to explain these technologies.)
In the short term, the success of ActiveX will be found in the intranet setting. At the department or division level, software and hardware resources can be quantified and controlled to a much larger degree than in the entire Internet. Therefore, organizations that have already chosen Windows 95 or NT as part of their standard desktop should find implementing ActiveX solutions relatively easy. The advantages of ActiveX really show up in this situation, because the department's IS staff can continue to work with the tools with which they've been developing for the past few years. Developers can set up Web servers to provide replication, if necessary, and update objects on servers so that users see the changes in real time. In fact, they can even reuse existing OLE controls and ActiveX controls. At this point, the professional developer should look at encapsulating application logic in the form of distributed objects on servers. The user interface can be generated fairly rapidly using standard Web publishing tools. Developers can also use Java throughout development projects, in combination with ActiveX, to match the best tool with the job.
On the other hand, ActiveX faces a much more daunting task before it can claim success across the World Wide Web. Because of security concerns and the fact that a large number of World Wide Web clients are non-Windows machines, ActiveX on the Internet is met with skepticism by most developers. As Microsoft demonstrates the effectiveness of its code-signing solution, and as ActiveX is ported to other platforms, ActiveX should slowly gain a larger measure of support than it currently is receiving.
In any case, to reach the lowest common denominator, pure Java is still the best choice for providing active Web applications to the greatest number of clients. Despite its flaws, the Java language and runtime environment were designed with the Web in mind (not retrofitted for the Web after the fact) and contain several advantages simply not found in any other technology on the market today. The following example illustrates the use of Java (using Microsoft Visual J++) to build a COM-aware Java applet.
No matter how you look at it, the Web developer skilled in Java and COM/ActiveX has the best of the desktop and the Internet at his or her fingertips. The Visual J++ development tool enables the Java programmer to call COM objects using Java code. These COM objects look exactly the same to the developer as every other Java class. In fact, using tools included with Visual J++, actual Java class files are generated for each COM object. These classes can then be imported and used just as if they were a standard class.
This "magic" is made possible through the use of the Microsoft Virtual Machine for Java. Microsoft has licensed the JVM spec from Sun Microsystems and has signed an agreement to build the "reference implementation" of the JVM for the Windows platform. Any additions made to the Windows JVM by Microsoft can then be given back to Sun for inclusion in the Java Virtual Machine Specification, owned by Sun Microsystems. Unlike the virtual machine included with most Web browsers, such as Netscape Navigator, the Microsoft Virtual Machine actually becomes part of the operating system after installation. This means that it is then available to all Windows applications. Because it is itself implemented as a COM object, the Microsoft Virtual Machine can be utilized by any application that supports the same COM interfaces. This enables objects created in Java to appear as COM objects to other Windows applications. In providing this, Microsoft has elevated Java to the same programming status as its other flagship languages: C++ and Visual Basic.
The javabeep example included with Visual J++ demonstrates a Java class-calling COM object (located in the beeper.dll file). This simple object is used to build a Java applet and application that will beep and print a message each time the user clicks the mouse on the application's client window.
Using the Java Type Library Wizard in Visual J++, standard Java
classes are generated from the COM object's type library.
| NOTE |
A type library in COM is simply a "definition" file that lists all of the methods, variables, and interfaces supported by the object that the type library represents. It can be thought of as similar in nature to a C++ header file. |
These classes provide a mapping between the variables, methods, and interfaces used in the COM object, and the variables, methods, and interfaces in the new Java class. When the Type Library Wizard is finished, two new classes will have been created for your use in the \windows\java\lib\beeper directory:
At this point, to access these two objects (actually contained in the beeper.dll COM library), add the following line of code to your Java applet or application:
import beeper.*;
This will import both classes in the Beeper package. To create a new beeper object for use within your Java class, the following code is sufficient:
IBeeper m_Beeper = null; ... if(m_Beeper==null) m_Beeper = (IBeeper) new Beeper();
After the object has been created, the following statement will call into the beeper.dll and issue a beep:
m_Beeper.beep();
Programmers with some Java experience should notice that syntactically there is nothing here but standard Java code. The real work is being done at the Virtual Machine level. Figure 10.3 shows the javabeep project running as an application.
Figure 10.3 : A Java application calling a COM object.
Figure 10.4 shows the javabeep project running as an applet.
Figure 10.4 : A Java applet calling a COM object.
The ActiveX technologies are extremely powerful and have the potential to enable Web-based applications to do things that were previously impossible. Using ActiveX controls, ActiveX scripting, and ActiveX documents in combination with HTML and Java applets, the software developer can develop truly interactive, interesting applications using the Web browser as the operating environment. With a tool such as Visual J++, the ActiveX controls can even be built using Java, and Java applets can contain ActiveX controls. This gives the professional software developer the best technologies of the desktop, combined with the best technologies of the Internet.
ActiveX itself comes with several advantages and disadvantages. It has the advantages of being language independent, having good performance, and a large existing code base. Some of its drawbacks include its platform dependence (it can be used only on Windows at the current time), its access to the local operating system, and its level of browser support (only Internet Explorer at the current time).
Microsoft is taking steps to address each of these issues and will eventually get there, but many developers are comfortable with the capabilities of Java as it currently exists. To port ActiveX to a small number of desktop operating systems requires an extensive effort, while the Java Virtual Machine already exists on nearly every operating platform in use today. ActiveX security (via code signing) requires an independent certification authority to certify and verify a control's behavior.
Tools such as Visual J++ enable Java developers to pick and choose among different Java, COM, and ActiveX objects and build applications using the best features of all three technologies. Visual J++ comes with three wizards designed to greatly enhance the productivity of the Java programmer.
These wizards, combined with a visual debugger, online documentation, and excellent development environment, give the Java programmer an extremely flexible tool that can be used for standard Java programming, as well as ActiveX programming.
Over time, it will become more apparent whether ActiveX's strengths are enough to overcome its inherent weaknesses. Until then, it is likely that both technologies will coexist and continue to improve. If this happens, it will be to the software developer's benefit.